Extreme Privilege Escalation 
on Windows 8/UEFI Systems 

Corey Kallenberg @coreykal 

Xeno Kovah @xenokovah 

John Butterworth (g)jwbutterworth3 

Sam Cornwell @sscOrnwell 



MITRE 



©2014 The MITRE Corporation. All rights reserved. 

Approved for Public Released 4-2221 



|2| 

Introduction 



■ Who we are: 

- Trusted Computing and firmware security researcliers at Tlie 
MITRE Corporation 

- What MITRE is: 

- A not-for-profit company tliat runs six US Government "Federally 
Funded Research & Development Centers" (FFRDCs) dedicated to 
working in the public interest 

- Technical lead for a number of standards and structured data 
exchange formats such as CVE, CWE, OVAL, CAPEC, STIX, 
TAXI I, etc 

- The first .org, !(.mil | .gov | .com | .edu | .net), on the ARPANET 
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Outline 



■ The agony of ring 3 

■ Escaping to the deepest, darl<est, depths of the system where 
few mortals dare tread 

■ 2 new take-complete-control-of-the-system-and-defeat-all- 
security BIOS exploits: The King's Gambit, The Queen's Gambit 

■ Disclosure timeline and vendor response 

■ The Watcher appears! 

■ Questioning your assumptions (and assessing your risk) with 
Copernicus 

■ Conclusion 
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Attack Model (1 of 2) 
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An attacker has gained administrator access on a victim 
Windows 8 machine 

But they are still constrained by the limits of ring 3 



) 2014 The MITRE Corporation. AH rights reserved 



mm. 



Attack Model (2 of 2) 




■ Attackers always want 

- More Power 

- More Persistence 

- More Stealth 
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Typical Post-Exploitation Privilege Escalation 




Ring 0 



Admin Ring 3 



■ Starting with x64 Windows vista, kernel drivers must be signed and contain 
an Authenticode certificate 

■ In a typical post-exploitation privilege escalation, the attacker wants to 
bypass the signed driver requirement to install a kernel level rootkit 

■ Various methods to achieve this are possible, including: 

- Exploit existing kernel drivers 

- Install a legitimate (signed), but vulnerable, driver and exploit it 

■ This style of privilege escalation has been well explored by other 
researchers such as [6][7]. 

■ There are other, more extreme, lands the attacker may wish to explore 
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other Escalation Options (1 of 2) 
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■ There are other more interesting post-exploitation options an 
attacker may consider: 

- Bootkit the system 

- Install SMM rootkit 

- Install BIOS rootkit 
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other Escalation Options (2 of 2) 
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Signed BIOS Enforcement 




Chipset Protection 



■ Modern platforms contain protections against these more exotic 
post-exploitation privilege-escalations 

- Bootkit the system (Prevented by Secure Boot) 

- Install SMM rootkit (SMM is locked on modern systems) 

- Install BIOS rootkit (SPI Flash protected by lockdown mechanisms) 
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Extreme Privilege Escalation (1 of 2) 



Platform 
Firmware (UEFI) 



SMM 



Boot Loader 
(MBR) 



Ring 0 



Admin Ring 3 



This talk presents extreme privilege escalation 

- Administrator userland process exploits tlie platform firmware 
(UEFI) 

- Exploit achieved by means of a new API introduced in Windows 8 

on. Afl riqhts rese 
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Extreme Privilege Escalation (2 of 2) 




■ Once the attacker has arbitrary code execution in the context of the 
platform firmware, he is able to: 

- Control other "rings" on the platform (SMM, Ring 0) 

- Persist beyond operating system re-installations 

- Permanently "brick" the victim computer MITRE 
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Target Of Attack 
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■ Modern Windows 8 systems ship with UEFI firmware 

■ UEFI is designed to replace conventional BIOS and provides a 
well defined interface to the operating system 
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Obligatory UEFI Diagram 
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REAKING IN EARLIER == MORE PRIVILEGE 
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Windows 8 API 



SetFirmwareEnvironmentVariable 
function 




Sets the value of the specified firmware environment variable. 

Syntax 



BOOL WIIMAPI SetFirmwareEnvironmentVariable( 
_In_ LPCTSTR IpName, 
_In_ LPCTSTR IpGuid, 
_In_ PVOID pBuffer, 
In DWORD nSize 



■ Windows 8 has introduced an API tliat allows a privileged 
userland process to interface with a subset of the UEFI interface 
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EFI Variable Creation Flow 
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SPI Flash 




■ Certain EFI variables can be created/modified/deleted by the 
operating system 

- For example, variables that control the boot order and platform 
language 

■ The firmware can also use EFI variables to communicate 
information to the operating system 
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EFI Variable Consumption 



SPI Flash 




■ The UEFI variable interface is a conduit by whicti a less privileged 
entity (admin Ring 3) can produce data for a more complicated 
entity (the firmware) to consume 

■ This is roughly similar to environment variable parsing attack 
surface on *nix systems 
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Previous EFI Variable Issues (1 of 2) 



Vulnerability Note VU#758382 

Unauthorized modification of UEFI variables in UEFI systems 

Original Release date: 09 Jun 2014 1 Last revised: 19 Jun 2014 



a Prtit J*- Tweet I E Send O ShaiB 



Overview 

Certain firmware implementations may not correctly protect and validate information contained in certain UEFI variables. 
Exploitation of such vulnerabilities could potentially lead to bypass of security features and/or denial of sen/ice for the 
platform. 

Description 

As discussed in recent conference publications (CanSecWest 2014. Syscan 2014, and Hack-in-the-Box 2014) certain 
UEFI implementations do not correctly protect and validate information contained in the "Setup" UEFI variable. On some 
systems, this variable can be overv/ritten using operating system APIs. Exploitation of this vulnerability could potentially 
lead to bypass of security features, such as secure boot, and/or denial of sen/ice for the platform. Please refer to the 
conference publications for further details. 

Impact 

A local attacker that obtains administrator access to the operating system may be able to modify-- UEFI variables. 
Exploitation of such vulnerabilities could potentially lead to bypass of security features and/or denial of sen/ice for the 
platform. 

We've already co-discovered[13] with Intel some vulnerabilities 
associated with EFI Variables that allowed bypassing secure 
boot and/or bricking the platform 

© 2014 The MITRE Corporatio^^f igh^r^erved. 
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Previous EFI Variable Issues (2 of 2) 



Vulnerability Note VU#758382 

Unauthorized modification of UEFI variables in UEFI systems 



Original Release date: 09 Jun 2014 1 Last revised: 19 Jun 2014 
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Overview 



Certain firmware implementations may not correctly protect and validate information contained in certain UEFI variables. 
Exploitation of such vulnerabilities could potentially lead to bypass of security features and/or denial of sen/ice for the 
platform. 

Description 

As discussed in recent conference publications (CanSecWest 2014. Syscan 2014, and Hack-in-the-Box 2014) certain 
UEFI implementations do not correctly protect and validate information contained in the "Setup" UEFI variable. On some 
systems, this variable can be overv/ritten using operating system APIs. Exploitation of this vulnerability could potentially 
lead to bypass of security features, such as secure boot, and/or denial of sen/ice for the platform. Please refer to the 
conference publications for further details. 



A local attacker that obtains administrator access to the operating system may be able to modify-- UEFI variables. 
Exploitation of such vulnerabilities could potentially lead to bypass of security features and/or denial of sen/ice for the 



■ However, VU #758382 was leveraging a proprietary Independent 
BIOS Vendor (IBV) implementation mistake, it would be more 
devastating if an attacker found a variable vulnerability more 
generic to UEFI luim 



Impact 



platform. 



©2014 The MITRE Corporation 




AH rights reserved. 



18 



UEFI Vulnerability Proliferation 
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If an attacker finds a vulnerability in the UEFI "reference 
implementation," its proliferation across IBVs and OEMs would 
potentially be wide spread. 

- More on how this theory works "in practice" later... 
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Auditing UEFI 



* 



Page Discussion 



Read View source 



UDK2014 
EDKII 

EFI Dev Kit (EDK) 
EDKII Build Tools 
Ail Projects 

▼ Information 
How to Contribute 
Getting Started 
FAQ, Acronyms 
Documents 
Training 

Reporting Issues 
Legalese 

► Navigation 



Welcome 



UEfl Development Kit 2014 (UDK2014) 

• * . » • Continuing with the 

^ * • ' * J UEFI Open Source Community 



This is the community site surrounding the open source components of Intel's implementation of UER. To learn how to use UER see our start using UER page. 

To learn more about getting involved in the community see our how to contribute page. EDK n is a modern, feature-rich, cross-platform firmware development environment for the UER and PI sp 
If you have any comments for this site please see the Community _Admins page. 
For the full list of our community projects, visit the Projects page. 

New Announcements 

March 20, 2014 

Announcing the new UDK2014 Release. Goto the UDK2014 page to download the release and documentation. The UDK2014 release will deliver the UER 2.4 and PI 1.3 support. Specific details on 
the UDK2014 Release Notes s^. 

Feb 11, 2014 

Upcomming soon UDK2014 See a sneak pre- view: UDK2014 Features 

Archived News News from 2009-2013 



http://tianocore.sourceforge.net/wiki/Welcome 



■ UEFI reference implementation is open source, making it easy to audit 

■ Let the games begin: 

- Svn checkout https://svn.code.sf.net/p/edk2/code/trunk/edk2/ 

on. Afl rights rese 
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Where to Start Looking for Problems? 



■ Always start with wherever there is attacker-controlled input 

■ We had good success last year exploiting Dell systems by 
passing an specially-crafted fake BIOS update... 

■ So let's see if UEFI has some of the same issues 

■ The UEFI spec has outlined a "Capsule update" mechanism 
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Where to Start Looking for Problems? 



Always start with wherever there is attacker-controlled input 

- Many of the UEFI variables are writeable by the OS, and are thus 
"attacker controlled" 

We had good success last year exploiting Dell systems by 
passing an specially-crafted fake BIOS update... 

The UEFI spec outlines a "Capsule update" mechanism for 
firmware updates 

- It's not directly callable by ring 3 code... 

- But it can be initiated by the creation of a special EFI Variable! 

- We considered this to be a good target 
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Capsule Scatter Write 



Firmware Capsule 



FFFFFFFF. 



CAPSULE HEADER 
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_FILE 




FIRMWARE, 


_FILE 



Operating System 





Capsule Data Block 0 



Capsule Data Block N-1 



Capsule Data Block 1 



00000000 



To begin the process of sending a Capsule update for 
processing, the operating system takes a firmware capsule and 
fragments it across the address space 
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Capsule Processing Initiation 



"CapsuleUpdateData" = 3E700000 



FFFFFFFF 



3F000000 



3E700000 



3E000000 



SetFirmwareEnvironmentVariable 




3D000000 



00000000 



Capsule Data Block 0 



DescriptorArray (BlockList) 



Capsule Data Block N-1 



Capsule Data Block 1 



DescriptorArray[0] 

Length=0x20000 
DataBlock=3F000000 



DescriptorArray[l] 
Length=0x20000 
DataBlock=3D000000 



DescriptorArray[N-l] 

Length=OxlOO 
DataBlock=3E000000 



■ The operating system creates an EFI variable tliat describes tlie 
location of the fragmented firmware capsule 

■ A ''warm reset'' then occurs to transition control back to the 
firmware 
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Capsule Coalescing 
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The UEFI code "coalesces" the firmware capsule back into its 
original form. 
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Capsule Verification 
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UEFI parses the envelope of the firmware capsule and verifies 
that it is signed by the OEM 
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Capsule Consumption 



FFFFFFFF 



Consume Capsule 




00000000 



Contents of the capsule are then consumed.... 

- Flash contents to the SPI flash 

- Run malware detection independent of the operating system 

- Etc... 



SPI Flash 
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Opportunities For Vulnerabilities 
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■ There are 3 main opportunities for memory corruption 
vulnerabilities in the firmware capsule processing code 

1 . The coalescing phase 

2. Parsing of the capsule envelope 

3. Parsing of unsigned content within the capsule 

■ Our audit of the UEFI capsule processing code yielded multiple 
vulnerabilities in the coalescing and envelope parsing code 

- The first "BIOS reflash" exploit was presented by Wojtczuk and 
Tereshkin. They found it by reading the UEFI code which handled 
BMP processing and exploiting an unsigned splash screen innage 
embedded in a firmware[1] 
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Bugs Galore 



if C*MemorySize <= (CapsuleSize + DescriptorsSize) > { <= Bug 1 
return EFI_BUFFER_TOQ_SMALL ; 

> 



// 

Desc = (EFI_CAPSULE_BLOCK_DESCRIPTOR * 
J- else i 

Size += CUINTH) Desc->Leiigtlii <= Bug 2 
Count ++ ; 



LbaCache = Alloc at ePool 


(FvbDev- 


■>NuiiiBlocks * 


sizeof (LBA_CACHE) ) ; 


<= Bug 3 














if (((Buffi + Sizel) <= 
return FALSE; 

I 


= Buff 2) 


1 1 (Buffi >= 


(Buff 2 + Size2))) { 


<= Bug 4 





■ We spent ~1 week looking at the UEFI reference implementation and 
discovered vulnerabilities in the capsule processing code 

- We found 2 exploitable vulnerabilities code-named after chess moves. King's 
Gambit is in DXE phase, Queen's Gambit in PEI phase. 

■ The vulnerabilities allow an attacker to get code execution in the context of 
an almost entirely unlocked platform 
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Vulnerabilities Summary 



} else {' 

// 

//To enhance the reliability of check-up, the first capsule's header is checked here. 
//More reliabilities check-up will do later, 
it (CapsuleSize -- <d) { 

// 

//Hove to the first capsule to check its header. 

// 

CapsuleHeader - <EFI_CAPSULE_HEADER*) ( CUINTN)Ptr->Union.DataBlock); 
if (IsCapsuleCorrupted (CapsuleHeader)) { 
return NULLj 

} 

CapsuleCount -h-h; 

CapsuleSize = CapsuleHeader->CapsuleImageSizej 
ValidateCapsulelntegrity: Edk2/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c 

■ The presence of easy to spot integer overflows in open source 
and security critical code is... disturbing 

- "Many eyes make all bugs shallow"... so is anyone (defensive) 
looking? 
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Onward To Exploitation 
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■ The aforementioned code runs with read-write-execute 
permissions 

- Flat protected mode with paging disabled 

- No mitigations whatsoever 

■ However, successful exploitation in this unusual environment was 
non-trivial mitpf 

on. AH rights rese 
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Coalescing Exploit Success 
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FFFFFFFF 



Overwrite function pointer 



Adjust Next DestPtr 




UEFI Code 



UEFI Stack 



0 



ReturnAddress - DestPtr Two 



Shellcode Address 



Intended Coalescing Space 



Relocated DescriptorArray 



00000000 




B QQCHnQE] 
BIZlGDaaB 




Corrupt DescriptorArray 



Exploited using a multistage approach that involved corrupting 
the scatter-gather list 

- Achieves surgical write-what-where primitive 



See whitepaper for full details on the exploitation technique 
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Envelope Exploitation Success 



FFFFFFFF 



3EBE1E44 



3EB18E78 



3DE1A910 

3DE1A890 
183EDD5D 

00000000 



ProduceFVBProtocolOnBuffer Code 



ProduceFVBProtocolOnBuffer Stack 



FvbDev 



FvbDev->LbaCache 



Shellcode 





AttackerValue = 2D98CBF. 
Overwrites top of loop code on iteration=BB 
*(DWORD *)3EB21E42 = (AttackerValue * OxBB) % 0x100000000 
= 14E9CF8F 

= 85 CF E9 14 [endianness] 
*(DWORD *)3EB21E46 = BF 8C D9 02 [endianness] 



loc_3EB21E44: 
E9 14 BF 8C D9 
2D 5E 30 mev- 



jmp 183EDD5Dh 
e bx, [ e si + EFI_FW_VOL_BLOCK_DEVICE.Lb a C a ch e ] 



CI El 03 shl ecx, 3 

89 14 19 mov [ecx+ebx+LBA_CACHE . Base] , edx ; *(DWORD *)3EB21E42 = AttackerValue*! 

8B 56 30 mov edx, [esi+EFI_FW_VOL_BLOCK_DEVICE. LbaCache] 

8B 58 04 mov ebx, [eax+LBA_CACHE . Length] 

89 5C 0A 04 mov [edx+ecx+LBA_CACHE . Length] ^ ebx ; *(DWORD *)3EB21E46 = AttackerValue 

8B 55 F4 mov edx, [ebp+vLinearOff set] 

03 50 04 add edx, [eax+4] 

FF 45 FC inc [ebp+vBlocklndex] 

FF 45 F8 inc [ebp+vBlockIndex2] 

8B 4D F8 mov ecx, [ebp+vBlockIndex2] 

89 55 F4 mov [ebp+vLinearOf f set] , edx 

3B 08 cmp ecx, [eax] 

72 D4 jb short loc_3EB21E44 



Memory corruption took the form of a non-terminating loop writing 
partially controlled values 



Exploited by having non-terminating loop self-overwrite 

See whitepaper for full details on the exploitation technique 
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Exploitation Mechanics Summary 



■ See the whitepaper for the super nitty-gritty details 

■ Capsule coalescing exploit (Queen's Gambit) allows for surgical 
write-what-where primitive resulting in reliable exploitation of 
the UEFI firmware 

- Exploited using only Windows 8 EFI variable API 

- Stores payload at predictable physical addresses by spraying EFI 
variables onto the SPI flash 

■ Capsule envelope parsing vulnerability (King's Gambit) can be 
exploited but corrupts a lot of the address space 

- Systenn possibly left in an unstable state if not rebooted 

- Relies on a 3^^ party kernel driver to stage payload at a certain 
physical address 

■ In both cases, attacker ends up with control of EIP in the early 
boot environment 

© 2014 The MITRE Corporatio^^f igh^r^erved. 
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Exploitation Flow (1 of 9) 



FFFFFFFF 




I'm not satisfied by tine 
limits of Ring3, 1 must 
grow my power 



00000000 



Address Space 



: C:\Windows\syslem32\cmd.eKe 



nici*osoft Windows [Uei^sion 6.0.60021 
Copyright <c> 2006 Microsoft Corporation. All rights reserved. 

C:\Uindows\systen32 >vihoani 
nt authority\systcn 



Our Sith attacker is unimpressed with his ring 3 admin privileges 
and seeks to grow his power through the dark side of the force 

on. Afl riqhts rese 
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Exploitation Flow (2 of 9) 
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FFFFFFFF 




"Payloadl" 


= payload 1 




"Payload2" 


= payload 





=0 FFF92000 
=C> FFF91000 



"Payload2" = payload 



C> FFF90000 



HI 



SetFirmwareEnvironmentVariable 



00000000 



Payload 



Payload 



Payload 



Evil Descriptor Array 



Shellcode 



Attacker creates many copies of a payload variable 

- Payload contains evil capsule as well as shellcode 

Similar to heap spray, this technique puts the attackers payload at a 
predictable physical address MITRE 

on. AH rights rese 
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Exploitation Flow (3 of 9) 



FFFFFFFF 





'CapsuleUpdateData' 
FFF91000 



FFF92000 
FFF91000 
FFF90000 



CapsuleUpdateData 



Payload 



Payload 




Payload 



SetFirmwareEnvironmentVariable 



00000000 



Attacker prepares to initiate capsule update by creating the 
CapsuleUpdateData variable 
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Exploitation Flow (4 of 9) 



37 I 




■ Warm reset is performed to transfer context back to UEFI 

- "Warm reset" probably means S3 sleep but is implementation specific 
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Exploitation Flow (5 of 9) 
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00000000 



Capsule processing is initiated by the existence of the 
"CapsuleUpdateData" UEFI variable 

on. AH rights rese 
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Exploitation Flow (6 of 9) 
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00000000 



UEFI begins to coalesce the evil capsule 
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Exploitation Flow (7 of 9) 
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00000000 



UEFI becomes corrupted while parsing evil capsule 
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Exploitation Flow (8 of 9) 
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00000000 



■ Attacker gains arbitrary code execution in the context of the early 
boot environment 



- Platform is unlocked at this point 



) 2014 The MITRE Corporation. AH rights reserved 



mm. 



Exploitation Flow (9 of 9) 
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00000000 



Attacker can now establish agents in SMM and/or the platform 
firmware to do their bidding 
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Unnatural Powers 



■ With these new powers, an attacker can: 

- Brick the platform 

- Defeat Secure Boot[2] 

- Establish an undetectable SMM rootkit[8][5] 

- Subvert hypervisors[9] 

- Subvert TXT launched hypervisors[3] 

- Circumvent operating system security functions[11] 

- Survive operating system reinstallation attempts 

- Other? 
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Vulnerability Disclosure & Vendor Response 

http://www.kb.cert.org/vuls/id/552286 

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-201 4-4859 
http://cve.mitre.org/cgi-bin/cvename.cgi?name= CVE-2014-4860 

■ We told Intel & CERT about the bugs we found on Nov 22"^ 
(King's Gambit) and Dec 4*^ (Queen's Gambit) 2013 

- We conveyed that we would extend our typical 6 month 
responsible disclosure deadline, and we would be targeting public 
disclosure in the sumnner at BlackHat/Defcon 

■ MITRE sets a 6 month default deadline to help prioritization to fix the 
problems. Things without deadlines have a tendency to not get done. 

- We also directly contacted some of the OEMs that we had the 
ability to send encrypted email to 

■ Intel patched the bugs in the UEFI source code in January 2014, 
and they are patched in the latest stable UEFI Developers Kit 
(UDK) 2014 release (March 2014) 

■ Intel held multiple meetings with many OEMs and IBVs to 
communicate and clarify issues. They also asked the vendors to 
report which systems were vulnerable. 

© 2014 The MITRE Corporatio^^f igh^r^erved. 



Vulnerability Disclosure & Vendor Response 

http://www.kb.cert.org/vuls/id/552286 

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-201 4-4859 
http: //cve.mi tre.org/cgi-bin/cvename.cgi?name= CVE-2014-4860 

■ Then we didn't hear anything for a while. 

■ In June we started to get nervous that there was a mismatch in our 
expectations about what vendors would be telling us 

- We expected to get a list of before BlackHat of which BIOS revisions 
vendors had released that patched the vulnerabilities. 

- What we got instead was a taste of the bad old days where some 
vendors didn't reply Intel, others replied that they're not vulnerable 
when they actually are, and others replied under NDA and we don't 
know what they said. 

■ In July we had to start an aggressive follow-up campaign with 
OEMs and IBVs where we specifically went and looked at their 
systems to try and identify signatures that indicate the presence of 
the vulnerable code, so we could cite specific evidence that they 
were vulnerable. 



■ Moral of the story: BIOS vendors are not used to having to fix 
vulnerabilities. (And you the BIOS users are not used to having to 
patch them even if patches exist!) 
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Our current understanding 
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Vendor 


Response 




Intel 


Vulnerable, fixed in January & released in UDK201 


14 


Phoenix 


Vulnerable, fixed (see next slide) 




Insyde 


Not vulnerable (see next slide) 




AMI 


Vulnerable, fixed (see next slide) 


- 


HP 


Vulnerable, fixed (see 4 slides from now) 




Dell 


Suspect code found with binary analysis, but is do 
be quarantined or removed in upcoming releases. 


rmant and will 


Lenovo 
Panasonic 


Incorporating Phoenix updated source code 
Under inspecting with IBV 




Other Vendors Unknown, waiting for contact info 
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Vendor 



Phoenix 



AMI 



Response 



Based on our analysis, we believe that our product was 
vulnerable to the attacks based on exploiting the three bugs, as 
described in the whitepaper: 

1 . Integer overflow in determining if CapsuleSize + 
DescriptorSize > Memory size. 

2. Integer overflow with summation of descriptor array Length 
members in GetCapsulelnfo. 

3. Multiplication overflow with sufficiently large NumBlocks 
when allocating LbaCache buffer. 

These issues affected our currently shipping SCT3 products and 
were fixed as of May 23, 2014, and the updates were promptly 
provided to our customers. We verified that our new SCT4 
product is not affected by these issues. 

AMI has addressed the issue on a generic basis and is working 
with OEMs to implement fixes for projects in the field and 
production. End users should contact their board manufacturer 
for information on when a specific updated BIOS will be 
available. 



Insyde 



Insyde's Capsule Update code is not vulnerable to this attack. 



jd. 
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How can Vulnerability Coordination be Done 
Better in the Future? 



■ Stick with CERT for vulnerability disclosure 

- We originally asked Intel to coordinate both because the 
vulnerability was in their reference source code, but also because 
they have nnany IBV/OEM BIOS engineer contacts. 

- However Intel can only lean on OEMs/IBVs so hard, because at 
the end of the day they're also customers. 

■ The UEFI forum is in the process of setting up a UEFI Security 
Response Team (USRT) to better coordinate these sort of 
disclosures in the future. 

- Shooting to go live by Sept 1 

- The USRT will help work with the long-tail of vendors who are not 
the top-3 PC vendors who are the nnain ones we tend to focus on 
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■ In our whitepaper we discussed a concrete example of finding 
the UEFI reference source code vulnerabilities in a shipping HP 
Elitebook 2540p system. 

■ MITRE is not in any way endorsing or denigrating HP's products 
specifically. As with the Dell system we attacked last year, we 
did our analysis there just because we happened to have such 
systems easily available to us. 

■ So as we did last year with Dell, we'd like to invite a 
representative from HP to offer their thoughts on the 
vulnerabilities, their response, a point of contact for any future 
vulnerabilities, etc. 
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UEFI Vulnerability Briefing 



Introduction 

HP values the important contribution IVIITRE provides to the computing 
community 

HP treats all security issues seriously, and seeks to provide appropriate 
mitigations in a timely manner 

Individuals and organizations wishing to report security issues should 
contact our Software Security Response Team at this email address: 

securitv-alert(a)hp.com 
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UEFI Vulnerability Briefing 

The HP 2540p EliteBook 



This system shipped in 2010 

A 2540p BIOS update fixing this issue is available for download from the 
2540p "Support -> Drivers & Downloads" page at hp.com 

For additional information on this vulnerability please refer to the HP 
Security Bulletin at the following link: 

https://h20564.www2.hp.com/portal/site/hpsc/public/kb/docDisplav/?docld=emr na-c04393276 
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HP Su restart 



Developed with 

HP Labs 



HP SureStart is the first self-healing technology solution created to protect 
against Malware and Security attacks aimed at the BIOS 



Intentional 
malicious corruption 



Failed update or other 
accidental corruption 



Unknown cause 
of BIOS corruption 



Sure Start 
recovers the 

BIOS for 
uninterrupted 
productivity, 
anytime, 
anywhere. 




1. 100% Automatic recovery of BIOS boot block. 

2. If all copies of BIOS are compromised or deleted, a manual step for recovering BIOS is available. 

3. Applicable to 2013 EliteBooks and ZBooks. 



Features 



Self-healing: Autonnatic recovery fronn BIOS 

nnalware and security attacks^ 

Firnnware protection against Pernnanent 

Denial of Service (PDoS) attacks 

Detects, reports and allows auto recovery of 

Advance Persistent Threats (APTs) ainned at 

BIOS 



Problems it solves 



No user downtime waiting for IT/Service ticket^ 
Results in fewer help desk calls for crisis recovery 
or bricked units 

Secure by default; safeguards machine unique 
data 



Customer benefits 



Virtually uninterrupted Productivity 
Confidence in BIOS Rollout 
Reduce TCO; no need to reinstall/replace 
hardware^ 

Detection and recovery transparent to 
customer 
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Thank you 
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BIOS Attacks: So What? 

What Can Attackers Do If They Break Into BIOS? 



■ We get asked this question a lot, and our answer is 
"EVERYTHING! YOU CAN DO EVERY. SINGLE. THING!" or 

"A BIOS attacker has available to it a superset of the capabilities 
of all lower privileged attackers." 

■ But of course they can be excused for thinking we're just 
another group of security folks trying to spread FUD. 

■ We don't spread FUD, we talk about what we know to be 
technologically and architecturally possible. 

■ But maybe we should put the fear of God into people? 

■ Or at least... the fear of Galactus! 
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Marvel Comics 
Fantastic Four #1 3, 1 963 
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Presenting 
the first 
appearance 
of 

Tlie Watcher! 



AAITRE 
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The Watcher 



■ The Watcher lives in SMM (where you can't look for him) 

■ It has no build-in capability except to scan memory for a magic 
signature 

■ If it finds the signature, it treats the data immediately after the 
signature as code to be executed 

■ In this way the Watcher performs arbitrary code execution on behalf 
of some controller 



■ A controller is responsible for placing into memory payloads for 
The Watcher to find 

■ These payloads can make their way into memory through any 
means 

- Could be sent in a network packet which is never even processed by 
the OS 

- Could be embedded somewhere as non-rendering data in a document 

- Could be generated on the fly by some malicious javascript that's 
pushed out through an advertisement network 

- Could be pulled down by a low-privilege normal-looking dropper 

- Use your imagination MITRE 
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The Watcher, watching 
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RAM 



Design tradeoffs: 

We don't want to scan every 4 byte 
chunk of memory. So instead we scan 
every OxIOOO-aligned page boundary. 

How do we guarantee a payload will be 
found on a page-aligned boundary? 

a) Another agent puts it there 

b) Controller prefixes the payload with 
a full 0x1 000 worth of signatures 
and pointers to the code to be 
executed (this guarantees a 
signature will always be found at 
the boundary or boundary+4) 

There are obviously many different 
ways it could be built. 
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Attached 



(non-rendering) 
^^^payload^^^ 




ystem 
Management 
RAM (SMRAM) 



Controller 

positions 

payload 
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ITIMATElUlUnER: 



#130 



Slie: ApproM. 4.5" x 3,8" x 1* 

Weight: Approx. 4.5 lbs. 

Com position: Uthium-Boron-Osfnitjm alloy 

(speculative): Internal Ccimposltton: Unknown 




AJi mformauon h&arsa^ Devtes may have bM<i cmBifi^i 
before Ihe lime iliis universe, supposad^y destroys 
-.^■ly -nbjects 'compleiely tirdefstood" by potenual usar 
•fifi daslroys usgr as well Fstever used in Ihls 
dimension. 




ULTtUATE NULUf l£R MAHVEL ^'•MfcfV* 
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Demo 




Marvel Comics 



Fantastic Four #48, 1966 



Impel 1991 

Marvel Universe Series 2 



AAITRE 



Watcher Stats 
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■ A week to get dev env set up (I didn't have my SPI programmer) and to 
find where to insert the code into SMIVI so it got called on every SMI 

■ 2 days to write Watcher + basic print payload 

■ Watcher itself: ~ 60 lines of mixed C and inline assembly 

■ Print payload: 35 bytes + string, 12 instructions 

■ Ultimate Nullifier payload: 37 bytes, 11 instructions 



Overall point: very simple, very small, very powerful 

How likely do you think it is that there aren't already Watchers watching? 

But we can't know until people start integrity checking their BlOSes 
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The Watcher of Tomorrow 



■ One can imagine numerous ways that something like The Watcher 
could be made a lot harder to deal with in the future 

- Use Intel AES instructions to decrypt payload before execution (so 
that even if a malware analyst happened to catch the payload, they 
wouldn't be able to see the function unless they had already captured 
The Watcher and its AES key) 

- Include asymmetric crypto signature checking on payloads (so that 
only the one true controller can cause code execution) 

- Incorporate Smite'em[8] to hide the persistence in the BIOS flash chip 

- Every payload changes out the signature that will be searched for to 
find the next payload (to hinder network-based signature analysis) 

- Use formal covert channels for C2 (also to hinder network analysis) 

- Payloads wipe themselves from memory after execution (to defeat 
memory forensics) 

- Use your imagination 

■ Making malware isn't our gig. Understanding what's possible and 
creating strategies to defeat it is. 



2014 The MITRE Corporation. AH rights reserved. 




63 I 



Does the appearance of 
The Watcher portend the 
end of all things? 

Is this BIOS doomsday?! 

No! 

The Watcher (and other 
BIOS malware) can be 
taken down! 



Marvel Comics 
Fantastic Four #49, 1 966 



AAITRE 
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Copernicus. Nikolaus Copernicus. 



What can you do about it? 
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■ Run Copernicus. It has been updated to automatically report if your 
system is on the small list of currently known-affected systems for 
CERT VU # 552286 (the CERT VU and Copernicus will be updated 
as more vendors acknowledge their vulnerability) 

- http://www.mitre.orq/capabilities/cvbersecuritv/overview/cvbersecuritv- 
bloq/copernicus-question-vour-assumptions-about or just search for 
"MITRE Copernicus" 

■ We are now releasing our UEFI binary integrity checking script 
(bios_diff.py) for use on UEFI BIOS dumps. This can help you 
detect if your BIOS has been backdoored 

- You can often extract "known good" BIOS dumps from BIOS update 
applications. We have a basic collection, but this doesn't scale well. 

- We're going to be working with BIOS vendors to get a standard 
metadata format whereby they can provide true known good contents 
of the flash chips, and what should and shouldn't naturally change 
(e.g. where are the UEFI non-volatile variables, etc) 
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What can you do about it? 
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■ If you're in charge of an enterprise, start running BIOS updates 

- And start requesting your asset management software vendor 
include BIOS revision and vulnerability status information 

■ If you're a security vendor, start including BIOS checks 

- If you're a customer, start asking for BIOS checks 

■ We are happy to freely give away our Copernicus code to get 
vendors started with incorporating checking BlOSes. All we ask 
for in return is some data to help further our research and help 
show why BIOS security is so important. 

■ We want BIOS configuration & integrity checking to become 
standard capabilities which are widely available from as many 
vendors as possible. 

- No more massive blind spot please! 
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Qgy ^ Bootkit/UER: Dreamboot A UER Bootkit 

^Apple/SMC/KBC/EC/Rrmware: Practical Exploitation of Embedded Systems 

^I2C: Battery Rmiware Hacking: Inside the innards of a Smart Battery ^ Apple/SMC/KBC/EC/Rmiware: Apple SMC, The place to I 

lerabilities ^ AMT/ME/BIOS/Rrmware: Rootkit in your laptop >- Analytics, and Scalability, and UER exploitationi Oh Myl 

le fimnware integrity verification: what if you can't trust your network card? ► BIOS/UER/Rrmware/SecureBoot A Summary of Attac 
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: Backd coring Embedded Controllers ^ BIOS/UER/Rrmware/SecureBoot A Tale of one Software Bypass of Windows & 

► BlOS/SMM/Fiimware/TPM: BIOS Chronomancy: Fixing the Core Rootc 

irse engineering the Broadcom NetExtreme's Rmnware ► BIOS/Rrmware/SMM/SMX/TXT: Copernicus 2: SENTEI 

lity P- ACPI: ACPI 5.0 Rootkit Attacks "Against" Windows 8 ► BlOS/Firmware/SecureBoot/Bootkit: Setup for Failun 

■£ Rabbit Software attacks against lntel{R)VT-d technology ► BlOS/UEFI/Firmware/SMX/TXT: SENTER Sandm 

3C/EC: Sticky Rngers & K8C Custom Shop ► BIOS/UEFI/Rrmware/SecureBoot: Extreme f 

3 Boot^ ►BIQS/SMM/Firmware: Defeating Signed BIOS Enforcement 

http://timeglider.com/timeline/5ca2daa6078caaf4 aka 
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Summary 



■ We have found and disclosed two new exploitable vulnerabilities. 

■ These vulnerabilities would allow an attacker to take control of the 
system before any security is enabled, and persist indefinitely via 
the SPI flash chip. 

■ We have also invented a new technique to make BIOS/kernel 
exploits more reliable by staging shellcode into UEFI non-volatile 
variables, which will be mapped at predictable locations. 

■ We have shown The Watcher, which is an example of how an 
attacker can gain arbitrary code execution in the most privileged 
x86 execution domain. System Management Mode. 



We have updated our public "Copernicus" software which can 
integrity check a BIOS to look for backdoors, or check for the 
presence of known vulnerabilities. 
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Conclusions 



■ It's time to get serious about firmware security 

- Start patching your BlOSes 

- Start demanding firmware inspection capabilities 

■ UEFI lias more tightly coupled the bonds of the operating system and the 
platform firmware 

■ Specifically, the EFI variable interface acts as a conduit by which a less 
privileged entity (the operating system) can pass information for 
consumption by a more privileged entity (the platform firmware) 

- We have demonstrated how a vulnerability in this interface can allow an 
attacker to gain control of the firmware 

■ Although the authors believe UEFI to ultimately be a good thing for the 
overall state of platform security, a more thorough audit of the UEFI code 
and OEMs/IBVs' extra "value added" code is needed 



MITRE'S Copernicus continues to be updated and remains the only 
enterprise-deployable system that can integrity check and vulnerability 
check your BlOSes 

- But MITRE doesn't make products so industry needs to come talk to us 
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Questions & Contact 



■ {ckallenberg, xkovah, jbutterworth, scornwell} @ mitre . org 

■ Copernicus @ mitre . org 

■ @coreykal, (g)xenokovah, (a)jwbutterworth3, (g)sscOrnwell 

■ @MITREcorp 

■ P.S., go check out OpenSecurityTraining.info! 

■ @OpenSecTraining 
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